The present invention relates to a method to provide authorization by a certifying authority to a service provider to execute predefined functionality when a service is provided by the service provider to a terminal of a user, the method including the step of delivering a certificate, to a certifying authority. The present invention is also related to a terminal, a service provider and a certificate realizing the method and to a telecommunication network comprising a certifying authority, a terminal and a service provider.
Such a method for use in a telecommunication environment to provide authorization by a certifying authority to a service provider to execute predefined functionality in the event when a service is provided by the service provider to a terminal of a user, is already known in the art. Indeed, in such an event the certifying authority delivers a certificate to the service provider that provides the service provider the authorization to execute all the functionality of the telecommunication environment. Such a certificate is explained in the ‘Frequently asked questions about today's cryptography, version 4.0′’ published by RSA laboratories, a division of RSA Data Security in 1998. Herein, the answer to question 4.1.3.10. ‘What are certificates’ describes the object of a certificate. Certificates are digital documents attesting to the binding of a public key to an individual or other entity. They allow verification of the claim that a specific key does in fact belong to a specific individual. Certificates help to prevent someone from using a phony key to impersonate someone else. Certificates are typically used to generate confidence in the legitimacy of a public key. In some cases it may be necessary to create a chain of certificates, each one certifying the previous one until the parties involved are confident in the identity in question. Such a certificate contains a public key and name. As commonly used, a certificate also contains an expiration date, the name of the certifying authority that issued the certificate and a serial number. Most importantly, it contains the digital signature of the certificate issuer. The most widely accepted format for certificates is defined by the ITU-T X.509 international standard. Thus certificates can be read or written by any application complying with X.509.
Another application of certificates is described in the WAP WTLS, Version 30-Apr. 1998, Wireless Application Protocol, Wireless Transport Layer Security specification. Herein the content of such a certificate is described at page 57, paragraph 10.5.2: a version of the certificate, the algorithm used to sign the certificate, the certification authority who signed the certificate, the validity period of the certificate, the owner of the key, the type of the key, parameters relevant for the public key and the public key that is being certified. The use of such certificates is described now in the following paragraph.
A service provider can send a service to a terminal of a user. These services can contain functions that do e.g. call control on the phone whereby any service provider can take over control of the phone e.g. make calls and accept or reject calls. In order to prevent malicious service providers from abusing someone's phone, a certificate based authentication system is used. Only if the service provider can present a certificate that is signed by a certifying authority e.g. a telecommunication network operator, the service provider is allowed access to these dangerous functions. The service provider is allowed to use predefined functionality when the service is provided by the service provider to a terminal of the user.
It has to be remarked that the expression ‘a service is provided by the service provider’ means that for instance the content of a service is executed by a terminal of the user. When such predefined function is to be executed by the terminal, first, the terminal controls the presence of a signed certificate for the service provider. When such certificate is available the function might be executed without e.g. any danger for abuse of the terminal.
A further remark is that a certifying authority can be a network operator itself. However, according to actual trends, such certifying authority can be a service provider itself that provides the service to a network operator of the management of giving or refusing such certificates.
Yet, it has to be remarked that the verification of the existence of a signed certificate implies different steps like a certification process, a certificate distribution and validation whereby public key/private key PKI algorithms are involved in order to provide a digital signing of the certificate. These steps are known steps to a person skilled in the art and are therefor not described in details here. The aim is the signing of a certificate and the fact that this signature can be controlled.
A problem outstanding with the existing certificates is that they are all or nothing solutions. This means that a service provider can get access to all functions or to no function i.e. a certificate is delivered or no certificate is delivered by the certifying authority.
Such a situation is often not sufficient for a network operator. Indeed, a network operator can not risk that a service provider may eventual by accident disable services to some terminals.
The problem becomes more clear with the following example. Presume a situation where a network operator trusts some service provider enough to let him modify the digital personal telephone book of a user, but the network operator does not trust the service provider enough to give him access to all functionality i.e. delivering a certificate. A solution to this problem is to add this function to the public library. This means that the network operator allows the use of this function by all service providers according to predefined specifications e.g. specifying the function in such a way that the user is previously asked permission by a service provider to add a predefined entry in its telephone book. However, in such an event, also service providers that are trusted completely should work with the public function. Otherwise, both functions must be created i.e. one public function and one non-public function. This is resulting in a very complex, resource expensive and still not completely satisfying specification.